[速報レポート] try! Swift TOKYO 2017 2日目 午後II #tryswiftconf

[速報レポート] try! Swift TOKYO 2017 2日目 午後II #tryswiftconf

Clock Icon2017.03.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

try-swift-tokyo-2017-2nd-day-pm2

こんにちは。モバイルアプリサービス部の平屋です。

前記事に引き続き、try! Swift TOKYO 2017 のセッションの内容をレポートしていきます。

「チームの生産性を改善するために決断疲れを最小化する」Derek Lee さん

概要

ソフトウェアエンジニアとして、私たちは書いているコードの1行1行ごとに決断し続けています。 これに必要な時間とエネルギーの量はチームが生産的に働けるか、あるいは停滞させてしまうのかどうかを決定します。このトークではSwift開発における決断疲れを最小化し、チームの効率と同時にコミュニケーションとコラボレーションを改善する方法についての個人的な経験を共有します。

スライド

説明

  • 生産性向上に関係する話
  • どうすれば決断疲れを最小化できるか
    • 実際にやっていることを紹介
  • ソフトウェアエンジニア
    • 様々な決断が必要
    • 毎日毎日
    • 集中必要、難しい
  • 決断疲れ
    • 簡単なものを選んでしまったり
    • 悪循環起こる
    • 技術的負債
  • どうやれば疲れ減らせる?
    • 意思決定をシンプルにしよう
  • 発表者の所属する会社の日常の例
    • 朝飯何食べよう?: 提供される
    • 朝礼: 情報共有
    • プロジェクトの朝礼
      • 何やったか、何やるか、何か問題あるか
    • ペアプロ
    • ランチ
    • プランニング
      • 週1,2
      • チーム全体のコードベースを共有
    • 休憩
      • 卓球: 頭を切り替えられる
    • レトロスペクティブ:金曜にやる
      • コアメンバー全員でやる
      • 食事、飲み物提供
      • 感情にフォーカスする
      • keep, discuss, Improve それぞれについて話す
      • アクション必要であれば決める
      • ファシリテータは、楽しく終われるようにする
  • Xcodeプロジェクトの組織化
    • Xcodeでファイル探す方法
      • 複数ある
      • プロジェクトに詳しくないと、長い時間費やされる
    • グループで分ける?
    • 3つに分けた
      • Application: appdelegate, info.plist など
      • コンポーネント: API, Presenter...
      • UI: VC, View
  • ペアプロ, XP
    • コミュニケーション深められた
    • 物理的に2人で並んで
    • 2枚画面ミラーリング
    • 2つのスタイル
      • ピンポン: 交代でやる
      • ドライバ+ナビゲータ
    • エンジニア同士だけではない、デザイナ、PMも
    • ペアや作業内容は、定期的に変える
    • コードベースを共有できる
    • フィードバック速い、意思決定早くなる
  • Swiftファイル組織化
    • どのファイルに、どのコードを入れるか
    • 見つけやすくしたい
    • ViewControllerのメソッド
      • MARK: - 使ってセクション化する
    • ViewControllerのSnippet使っている
    • プロトコルの適用
      • extention に分ける + MARK: - 使う
  • エンジニアとデザイナのペアプロ
    • デザインの一貫化
    • スタイルガイドに従って、実装、再利用
      • カラー、フォントのextention
      • スタイルのenum
      • UIコンポーネントのextentionで、スタイル適用
  • 意思決定が繰り返すようであれば以下を考えよう
    • 自動化出来ないか?
    • 楽にできないか?

「Client-Side Deep Learning」Shuichi Tsutsumi さん

概要

iOS 10よりMetal Performance Shadersフレームワークに畳み込みニューラルネットワーク(CNN)のAPIが追加され、iOSデバイスのGPUを利用して高速にCNNの計算を行えるようになりました。つまり「ユーザの手元で」「オフラインでも」昨今の進化がめざましいディープラーニングの成果を利用できるようになったのです!本LTでは実装のオーバービューと、デモをお見せしたいと思います。

スライド

説明

  • iOS 10 で追加された CNN APIs について
  • Apple のサンプルアプリ
    • 数字を手書きして、それを認識するアプリ
    • リアルタイムに物体認識するアプリ
  • MPSCNN
    • Metal: appleハード用のAPI
    • これまで
      • サーバーでやってた
    • 今は
      • クライアントでDeepLearningできるようになった
  • DeepLearning は iOS でできるの?
    • 機械学習自体は強力なマシンで
    • iOSでは、学習済みのものを使う
      • これがMetalでできるようになった
  • iOSでできるようになったのは何が嬉しい?
    • サーバー負荷、ネットワーク負荷減る
  • DeepLearning 事例
    • 自動運転
    • Alpha Go
    • 医療
  • Deep Learning is something great
    • なにかすごい物がiOSで使えるようになった!

「オープンソースコミュニティをスケールさせる」Felix Krause さん

概要

オープンソースプロジェクトのさまざまな段階についてお話しします。どのようにプルリクエストを処理するか、規模に応じてどのようにサポートを変えていくか、ユーザー数が拡大していく中でどのように革新を起こしつづけるかをお話しします。 それらを念頭に置き、開発者がどのように問題を解決するのか、具体的にはワークフローの自動化、コントリビュータとの密接な関わり合い、プロダクトやドキュメントの改善について詳しく説明します。 おととしfastlaneで多くのことを学びました。オープンソースコミュニティのスケーリングについていくつかブログを準備しはじめました。

スライド

説明

  • fastlane
    • コントリビュータ500人以上
    • 何万人のアクティブユーザー
  • OSSのステージ
    • 1.ソースコード公開
    • 2.利用される
      • pr issue 来る
    • 3.デファクトになる
    • 4.毎日のように通知が来るようなレベルになる
  • OSSのスケーリングはハード
    • 人との関わり方
    • サポート作業
    • スケールする時に起こる問題、解決策
  • 初期の勢いを保つ方法
    • ユーザーが増えると、サポートが増える
      • 質問、機能要望、etc...
    • 全てを受け入れると破綻する、却下も必要
      • ビジョンに合っているか?
  • メンテナは、ユーザーで居続けられなくなる
    • 欲しくて作ったけれども
  • メンテナとユーザーの視点は異なる
    • メンテナはissueに優先度つけないといけない
  • 製品内での、エラーメッセージを改善する
    • 赤字表示
    • スタックオーバーフロー、issueへのリンク表示
  • BOT を使う
    • issue
      • issue作成時にバリデーションする
      • issueの重複を検知する
      • issueが放置されていると、issueをクローズする
    • プルリク
      • danger使う
  • 方向性を保つ
  • コードをシンプルに保つ
  • 貢献者にフレンドリーに接する
  • DSL
    • Fastfile
  • プラグイン
  • 最後に
    • OSSには課題が沢山ある
    • コミュニティに助けを求めよう
    • 大変だけど、大きな見返りを感じる

「Swiftでのエラーハンドリングとエラー耐性についての教訓」Christopher Rogers さん

概要

ソフトウェアを書いているとき、私たちはハッピーパス(例外やエラーが発生しない正常系のこと)についてはちゃんと考慮する一方、潜在的な障害についての考慮はおろそかになりがちです。しかしアプリが考えていたよりも長く、いろいろな状況で使われるようになると、コードはより複雑に分岐します。この講演では、あなたのアプリのエラー耐性を高めて少しでも'アンハッピーパス'がユーザーやアプリを保守する人たちにもたらす憂鬱を軽減するために、Lineで遭遇した様々なタイプのエラーに対処するために学んだ教訓を紹介します。

スライド

説明

  • 背景、念頭に置くこと
    • 自分たちのやりたいことをやってくれるコードを作りたい
    • 予期しない不具合から復帰し、ユーザーへの影響を最小限にしたい
  • 正しいコードを書くには?
  • 入力について
    • 明示的入力:関数の引数、self
    • 暗黙的入力:状態
      • グローバル変数、Singleton
  • 時間的状態
    • 大概は暗黙的
    • 順番守らないとコンパル出来ないようすることもできる
  • リアル世界の状態
    • 手に負えなくなりがち
  • 例: データフォーマットのマイグレーション
    • テーマをUserDefaultに保存
    • アップデート後の初回起動時にマイグレーションしたい
    • 移行処理がうまくいかないケースがあった
    • 「型による明示的な依存関係」を使う
  • Swift のエラー型 vs Optional
    • Optional
      • 正しい/正しくない, 有り/無し
    • エラー型 の使いみち
      • 不正解、正常に処理できなかった
      • 致命的な問題に使う
      • 発生率低・影響範囲の広いエラーに使う
  • 入出力の流れを意識しよう!

「? & ⌚️」giginet さん

概要

このトークでは、watchOS 3上で動作するゲーム開発の手法についてお伝えします。最新デバイスで動く、懐かしのゲームに思いを馳せてみてください。

スライド

説明

  • ゲーム&watchというタイトル
  • 古くから人類は時計でゲームを作ることに挑戦してきた
  • watchOS上で動くゲーム開発
    • watchOS上で動くファミコンシミュレータを実装しました。
    • NeS Emulatorの波形をSpriteKitを作って描画しました。
  • SpriteKitのエミュレータからピクセルを受け取って描画しています
  • エミュレータで生成した波形データをAVFoundationで音を鳴らすことができた
  • 入力はwatchOSのジェスチャを利用
  • TouchDownをLongPressの時間を短くすることで実現した
  • 描画は60fps程度は可能
  • コードはgithubに公開しています。

「なぜ登るのか」TachibanaKaoru さん

概要

2010年の東京オリンピックでも正式種目に選ばれたボルダリング。今日は、ボルダリングは Swiftエンジニアにとって最適なスポーツであることを紹介したいと思います。今まで試したこともない人も、是非tryしてみてください。

説明

  • ロッククライミングについて話をします
  • ボルダリングについてお話しします
  • クライミングスポーツですけど、ツールを使うことも多い
  • ボルダリングのルール
    • ホールドを選択しながらゴールを目指すシンプルなルールです
  • おすすめ1
  • 体育の授業を思い出してください
    • チームスポーツはメンバのレベルが同じでは無いと面白くない
    • 一つの壁に難易度の異なるコースがあるので、初心者、上級者が同じ壁に挑戦できる
  • おすすめ2
    • 登れなかった時は?
    • 身体能力に長けている部分は人それぞれに違う
    • 自分だけにあってるソリューションを考える
  • おすすめ3
    • ひとりでやるスポーツです
    • グループでのぼることもできる
    • ひとりでも集団でもできるスポーツです
  • Swiftは初心者でも上級者でも楽しむことができる
    • 各々のソリューションを状況に合わせてつくっていく
    • 一人でやることもあるが、グループでやることもある
    • 苦しい体験を世界中の皆さんと共有していきましょう

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.